Increasingly, individuals governments, and enterprises are relying on the Internet to conduct their affairs. The primary mechanism to conduct affairs over the Internet is a World-Wide Web (WWW) browser.
Some browser transactions of users are innocuous requiring little to no security. Yet, many transactions are either sensitive in nature or are types of transactions where the users do not want any record of their actions recorded or tracked. In other words, the users want anonymity and privacy.
One issue with using a browser for a sensitive communication between a user and an Internet server is managing a communication session. Users will conduct many transactions during a typical session with a server and yet they expect to authenticate and login just once for the session to that server. This only makes sense because otherwise, security would be too cumbersome and nearly unusable if a user had to re-authenticate to the server for each transaction of the session. Thus, the user needs to login just once per session and use his/her browser for many different activities that require the user to be authenticated. This is generally achieved by setting a cookie on the user's browser at authentication time and then checking this cookie transparently each time the user accesses a resource that needs to be checked for authentication. The cookie becomes the authentication token that proves authentication to the server after the user has provided their credentials.
A significant security risk is present with this approach. For example, if the cookie is exposed to an eavesdropper, then the eavesdropper may use the cookie on any browser and impersonate or act as the authenticated user. Furthermore, because cookies are generally sent with every request or transaction from the user's browser they have a very high exposure rate to theft from eavesdroppers.
One approach to remove this threat is to always use Secure Socket Layer (SSL) communications for all transactions where the cookie is sent. However, with this technique one improperly configured server can expose the whole system to attack.
Here again, the problems associated with exclusively using SSL communications are known in the industry and there have been many different techniques proposed to fix the problems. One approach is to watch for the Internet Protocol (IP) address of the incoming request or transaction and only allow a cookie to be used if the IP address of the requesting browser is that which was used by the user when the user authenticated into the session initially. But, an intruder can fake the IP address and still hijack the session. The other issue with this approach is that the technique will often fail because the IP address sent with a transaction is really not the IP address of the user's browser but is most likely the IP address of a firewall server or a network address translation (NAT).
Essentially, cookies can be reused by rogue users on different browsers and this poses a substantial security risk to users.
Consequently, there is a need for improved techniques for ensuring secure network communication sessions.